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REMARKS 

Claims 1, 5, and 7-23 remain in this application. Claims 2-4 and 6 are hereby canceled 
without prejudice or waiver of the right to pursue the subject matter of said claims in this or 
another applicatioin. Claims 1, 5, 7-8, 15, 18 and 21-23 are hereby amended. All other claims 
remain the same. Reconsideration of the claims as presented is requested. 

Claim 1 has been amended to eliminate the preamble of element b. and specify more 
clearly which of the elements are required and which are optional in the claimed system. Support 
for this language is inherently found in original claim 2, which specified, "at least two of the 
logic engines are present". Subsection b.i. (now c.) has been renamed as subsection c. and 
amended to specify that the transaction client agent resides on a node "distinct from and at a 
different locale than the nodes of the first and the second party" and to eliminate "another node 
of another system" and to specify receipt of data from a "payment processing gateway". Support 
for this language is found in original subsection b.iii. and original claim 3 and in the specification 
as originally filed (pg. 14, lines 14-27; pg. 20, line 25 to pg. 21, line 8; pg. 22, line 15, pg. 24, 
line 17-26). Subsection b.ii. (now d.) has been amended to specify that the third party fee 
calculation agent can also transmit data to the "third party fee fulfillment client logic engine". 
Support for this subject matter is found in the specification as filed (pg. 17). Subsection b.iii. 
(now e.) has been amended to reconcile its language with amended subsection b.ii as detailed 
above. New subsection f. was added to clarify the definition of a node and more clearly identify 
the first and second parties. Support for this language is found in the specification as filed (page 
18, lines 8-9; page 21, lines 4-5) and original claim 6. 

Claims 21-23 have been amended to add some of the same language added to claim 1. 
Support for the added subject matter is as set forth herein. 

Claims 1, 15, 18, and 21-23 have been amended to provide correct antecedent basis 
within and across the claims and reconcile the language of the claims such that the phrase "client 
agent" has been replaced with the term "client logic engine" as appropriate. Applicants note that 
the term "client logice" is found the specification (Summary of the Invention) and original 
claims. 

Claims 5 and 7 have been amended to change the dependency thereof due to claim 
cancelations. 

Claim 8 has been amended to correct grammatical errors. 
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Claim 21 has been amended to specify that the transaction client logic engine receives 
one or more data packets from a "payment processing gateway". Support for this subject matter 
is as set forth above for claim 1 . 

Claim 8 stands objected to due to formalities. Applicants have amended claim 8 as 
suggested by Examiner. Applicants respectfully submit that this rejection has been overcome 
and request that it be withdrawn. 

Claims 21-23 stand rejected under 35 U.S.C. 101 as being directed to non-statutory 
subject matter for failure to recite computer-readable medium. Insofar as it may apply to the 
present claims, this rejection is traversed. 

The preamble of claims 21-23 specify "a ... agent residing on a node within a wide area 
network ". Accordingly, the system comprises hardware (node) and software (agent). Applicants 
note that a node is defined in the specification (pg. 21, lines 4-6) as being independently selected 
at each occurrence from a computer, server or gateway, each of which inherently comprises a 
machine-readable medium or memory. Applicants have amended claims 21 to 23 to define the 
node, said claims having previously been defined to require a node. Applicants have also 
amended claim 1 to define the node. 

Accordingly, Applicants submit that this rejection has been overcome and request that it 
be withdrawn. 

Claims 1-16 and 18-23 stand rejected under 35 U.S.C. 102(e) as being anticipated by 
Sullivan et al. (U.S. Publication No. 2003/0093320). Insofar as it may apply to the present 
claims, this rejection is traversed. 

For the purpose of clarification, Applicants note that the first party and second party 
named in each of the independent claims are generally the consumer/purchaser and merchant 
(service provider and/or goods provider), respectively, as parties to a transaction. The transaction 
client agent resides on a node that is distinct from (away from, at a different location/locale than) 
the nodes of the first and second parties. The transaction client agent receives from a payment 
processing gateway (that communicates with the consumer and/or merchant) transaction 
information (in information packets) regarding the transaction (between the consumer and 
merchant), analyzes the information, and determines of what action needs to be taken in terms of 
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to which other client agent or node (a third party fee calculation client agent or third party fee 
fulfillment calculation agent) the information should be transmitted (subsection c). The third 
party fee calculation client agent (again on a node different than the consumer or merchant node) 
receives information from the transaction client agent and determines if third party fees are owed 
and then transmits another information packet back to the transaction client logic agent or to a 
third party fee fulfillment client agent (subsection d.). The third party fee fulfillment client agent 
(again on a node different than the consumer or merchant node) receives information from the 
transaction client agent or the third party fee calculation agent, determines the third party fees 
owed, effects deduction of third party fees from funds flowing between the consumer and 
merchant, and effects transfer of third party fees to the third party(ies) (subsection f.). 
Generalized flowcharts depicting the relationship between the parties and data transfer is detailed 
in FIGS. 1-4, 9, 1 1 and 13 and more generally in the exemplary embodiment depicted in the logic 
flowchart below. 



Payment 
Processing 
Gateway 



-► Merchant 



Transaction client agent 



3 r Party fee calculation 
client agent 



_ 3 rd Party fee fulfillment 
client agent 



The flow of information and funds as detailed in the claims, the figures and the diagram 
above is different than as disclosed or suggested by Sullivan et al. 

Applicants respectfully submit that Examiner appears to be mischaracterizing the 
disclosure of Sullivan et al., which is primarily directed to a complex tax compliance system. 
Sullivan discloses that the tax compliance system is not located within the systems of the seller. 
Sullivan discloses a system that is external to those of the merchant and that performs tax 
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compliance functionalities; however Sullivan requires that his tax system receive transaction data 

from the seller's computer network, and then transmits the tax data back to the seller's computer 

network (the original input source of the transaction) [Para 0005]. The compliance system 

records the tax data in order to: (i) complete a tax return; (ii) defend an audit; and (iii) provide 

tax planning data. [Para 0005] Sullivan's system is a control center that manages the different 

components of tax compliance - it (i) receives data from the accounting system; (ii) processes 

and calculates taxes owing; (iii) returns taxes owing to the accounting system; (iv) stores tax 

data; which leads to (iv) generate tax returns and load them to the systems of the state tax agency; 

and (v) generate payment instructions to the banking system. 

[0005] Transaction tax compliance burdens can be eased through application of a 
transaction tax compliance system that allows sellers or purchasers to calculate, record, 
and report the tax liabilities for transactions. Sellers and purchasers, through their billing 
or purchasing systems, cash registers, and/or websites, may transmit transaction data to 
one or more centralized processors through telecommunications technology or via their 
own computer networks. The transaction tax compliance system thereafter calculates the 
appropriate tax liability for the transaction by determining at least one of the following: 1) 
whether a taxable event has occurred, 2) where the taxable event occurred, 3) whether the 
transaction is subject to standard or special transaction tax laws or rules, and 4) who is 
responsible for reporting and remitting the tax liability. The tax liability is then 
transmitted back to the input source of the transaction for application to a sales order, 
purchase order, invoice, ecommerce checkout screen, or other transaction documentation. 
The transaction tax compliance system also records the tax liability for use in completing 
a tax return, defending an audit, or tax planning. 

Effectively, Sullivan's system is the hub of a complex hub and spoke compliance system. 
This system was in use for many years before Sullivan's invention, in the form of a complex tax 
compliance system located within the seller's infrastructure . Sullivan placed the system outside 
of the seller's infrastructure ; however, Sullivan still requires that the tax compliance system 
return the data back to the seller's system. 

Applicants acknowledge that the compliance system of Sullivan may be linked to the 

banking network and the tax authorities, which will allow the system to manage remitting tax 

liability and filing tax returns. [Para 007] 

[0007] The transaction tax compliance system may be linked to the banking network as 
well as to a computer systems used by tax authorities. This linkage would allow for the 
calculation, collection, recording, reporting, and remitting of a transaction tax liability 
through the transaction tax compliance system. Such a configuration would allow tax 
authorities to provide and monitor the transaction tax information applied by sellers and 
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purchasers to an extent not possible today. 

The Sullivan system, however, is still required to communicate directly with the systems 
of the seller to receive transaction data and to return tax liability data. 

On the other hand, the instant claimed system is located in the financial transaction 
system, it does not directly communicate with the systems of the seller . This may seem trivial, 
however it is extremely complex to deliver upon. 

The disclosed compliance system of Sullivan might be used to remit taxes; however, 
Sullivan does not disclose his system actually playing a role within the flow of funds between the 
buyer and seller. More specifically, in the Sullivan system, the compliance system returns tax 
amounts to the seller's system, to be integrated into the invoice. The Sullivan system is then used 
to collect / remit taxes. The seller's system collects the transaction amount (PLUS taxes) from 
the buyer. Sullivan does not disclose that his system is involved in this part of the transaction. 
Sullivan does not disclose a system actually integrating the taxes into the transaction data 
/ invoiced amount, to be collected from the buyer as a single amount . This is contrasted with the 
disclosed invention in which the compliance system is integrated within the banking / credit card 
system and flow of data. As a consequence, the retailer sends into the banking / credit card 
system a transaction amount that may NOT include taxes owing. The banking / credit card 
system is supposed to charge the account of the buyer with this transaction amount. 
HOWEVER, in the instant claimed system intervenes in the midst of this flow of data, to perform 
the compliance functionality and ADD the taxes calculated into the transaction amount. The 
banking / credit card system then charges the buyer's account with this AGGREGATE amount, 
not just the transaction amount that the seller originally sent out, as done by Sullivan. 

As detailed in claim 1 (which is diagramed in the flow chart above), the flow of 
information is different than the flow of information set forth by Sullivan. Accordingly, the logic 
required to achieve such differences in data flow, to manipulate the data, provide calculation and 
determination of third party fees and to effect fulfillment of third party fees are different than as 
disclosed or suggested by Sullivan. 

With regard to claim 21, Sullivan does not disclose or suggest a transaction client logic 
engine that "receives from a payment processing gateway one or more transaction data 
information packets related to one or more wide area network transactions between a first party 
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and a second party. . . wherein the transaction client logic engine resides on a node of a wide area 
network and at a different locale than the first party and second party ." The third party fee 
calculation logic engine of Sullivan requires direct communication with the merchant's/seller's 
node. There is no payment processing gateway between the consumer and merchant of Sullivan, 
in particular a payment processing gateway between the node of the transaction client logic 
engine and the nodes of the consumer and merchant. 

With regard to claim 22, Sullivan does not disclose or suggest a third party fee calculation 
client logic engine that " receives one or more information packets from a transaction client logic 
engine " and " transmits to the transaction client logic engine a transaction data information packet 
including said third party fees owed", wherein "the third party fee calculation client logic engine 
resides on a node with a wide area network distinct from and at a different locale than the nodes 
of a first party and a second party." The third party fee calculation logic engine of Sullivan 
requires direct communication with the merchant's/seller's node. There is no transaction client 
logic engine with which the third part fee calculation logic engine of Sullivan communicates 
transaction data. 

With regard to claim 23, Sullivan does not disclose or suggest third party fee fulfillment 
client logic engine that "receives from a transaction client logic engine or a third party feed 
calculation client logic one or more information packets", "causes the deduction of the third party 
fees owing from funds transferred between the first and the second party", "causes the transfer of 
the third party fees to said one or more third parties", AND "resides on a node with a wide area 
network distinct from and at a different locale than the nodes of a first party and a second party." 

Accordingly, Sullivan does not disclose the invention as claimed. Applicants respectfully 
submit that this rejection has been overcome and request that it be withdrawn. 

Claim 17 stands rejected under 35 U.S.C. 103(a) as being unpatentable over Sullivan. 
Examiner argues Sullivan discloses an authorization and capture client agent. Insofar as it may 
apply to the instant claims, this rejection is traversed. 

Applicants' comments above regarding the disclosure of Sullivan are equally applicable 
here as well. Applicants note that Sullivan fails to disclose an integrated system having the three 
different types of client agent of the instant claims, wherein the system determines whether or not 
third party amounts are owed and also affects payment of such amounts. 



- 12- 



Docket No. BAR-6 



Applicants respectfully submit that this rejection has been overcome and request that it be 
withdrawn. 



In view of all the foregoing, Applicants respectfully submit that they have made a diligent 
effort to place the application in form for allowance. An early notice thereof is respectfully 
requested. 

Respectfully submitted, 



Date: January 23. 2009 /RICK MATOS/ 

Innovar, L.L.C. Rick Matos 

P.O. Box 250647 Registration No. 40,082 

Piano, TX 75025-0647 Agent for Applicant 

Ph.: 972-747-7373 Email: innovarllc @ sbcglobal .net 

Fax: 972-747-7375 
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